Contact centers frequently receive calls from customers wishing to purchase an item or make a payment for a service rendered or goods purchased. A common form of making the payment involves conveying credit card information from the remote party. In the past, the remote party verbally indicated the card information to the agent, who would enter the information into a computer to process the transaction. This exposed the sensitive information of the credit card to the agent, and created a security weakness that allowed the potential for identify theft.
Past solutions attempted to automate the process by connecting the remote party with an interactive voice response unit (“IVR”). This allowed the remote party to enter their credit card using dual tone multiple frequency tones (“DTMF”) by pressing the keys on their phone. If the agent is not bridged onto the call, then the agent would not hear this information. However, in some instances, the agent would be bridged onto the call to facilitate the transaction and as a result, the agent would be exposed to the credit card information, albeit in the form of DTMF tones.
One approach for handling a credit card transaction is disclosed in U.S. Pat. No. 6,862,343 (“Vacek”). In this scheme, the agent would connect the call to an IVR when the transaction occurs, but doing so offers limited ability for the agent to know the status of the transaction as it occurs. That is, the agent is not fully aware of when information is entered by the remote party and is unaware of the transaction status until the transaction is completed. Another approach is disclosed in U.S. Pat. No. 8,275,115 (“Everingham”), but similarly offers limited ability for the agent to know the status of the transaction as it occurs. Further, the agent is muted when the remote party interacts with the IVR, so that the agent cannot assist the remote party if difficulties arise during the transaction. For example, if the remote party asks a question while interacting with the IVR, the agent cannot answer the question. Another approach is detailed in U.S. Pat. No. 8,750,471, (“Tew”) which defines a “safe mode” wherein DTMF tones provided by the remote party are blocked from the agent. This also offers limited ability for the agent to know the status of the transaction as it occurs. Furthermore, Tew describes an implementation for conventional telephone technologies, which is not applicable for a Voice over Internet Protocol (“VoIP”) environment. As will be discussed below, DMTF tones are handled differently in a VoIP environment as opposed to a conventional telephony technology environment.
Furthermore, all these approaches offer limited flexibility as to how prompts are provided to the remote party. Typically, only one approach is defined, i.e., the prompts are provided by an IVR, and the approaches do not provide a flexible configuration where prompts may be provided either by the agent or the IVR. Further, none of these approaches provide flexibility to allow the agent to control and monitor the status of the transaction as it happens without exposing the agent to the sensitive information.
Therefore, a need exists for an approach that provides flexibility as to configuring how the prompts are to be provided, without exposing the agent to the sensitive information in any form, and allows the agent to control and monitor the progress of the transaction as it occurs. It is with these and other aspects in mind that the concepts and technologies herein are disclosed.